Web services are a new breed of web application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the web. Web services perform functions that can be anything from simple requests to complicated business processes. Examples include: a credit checking service that returns credit information when given a person's social security number; a stock quote service that returns the stock price associated with a specified ticker symbol; and a purchasing service that allows computer systems to buy office supplies when given an item code and a quantity.
A web service may, for example, be based on shared, open, and emerging technology standards and protocols, such as SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration), and WSDL (Web Service Definition Language). In this environment web services can communicate, interact, and integrate with heterogeneous applications, irrespective of their implementation formats, thereby enabling web services to interact with one another across the Internet to facilitate dynamic integration between businesses, suppliers, partners, and customers.
The Web Services Description Language (WSDL) has been developed as a standard XML (eXtensible Markup Language) grammar for specifying properties of a web service, including what it does, where it is located and how to invoke it. WSDL describes a service as a set of ‘ports’ which group related interactions that are possible between the application (service requestor) and the web service (service provider). The interactions that are possible through a port are described as ‘operations’ which may have an input message and optionally a resulting output message. Each operation describes a potential interaction with the web service. This may be a request from the application to the web service. It could also be an interaction that can be initiated by the web service for which the application needs to take action. Interactions in either direction can be one-way or can require a response to be sent.
For example, a web service which provides an e-business application publishes its Universal Resource Locator (URL) in a well known UDDI directory. A client can then obtain the URL from the UDDI directory and contact the e-business application using the URL in order to obtain a WSDL document. The WSDL describes the interface provided for clients by the service e-business application, one or more transport mechanisms each supporting a communication protocol, for example SOAP over HTTP (HyperText Transport Protocol) and an end point address for each transport mechanism. Once a web client has the WSDL it can invoke the interface via the specified end point using the communication protocol of the specified transport mechanism. Further if the client has an e-business application with which the service e-business application may wish to communicate, the client and service may exchange WSDL documents in order to make this possible.
Many enterprises have a messaging-oriented internal network, using, for example, IBM's WebSphere® MQ, and WebSphere® Business Integration Message Broker (also known as MQSeries® Integrator (MQSI)). These enterprises increasingly want to integrate this messaging infrastructure with web service access, to allow services to be invoked from the messaging infrastructure using the standard web service protocols. Additionally, other non WSDL based protocols have been developed, and it is often not possible for a web client which makes use of one of these other, non WSDL based, business to business protocols, to communicate with web services which are described using a WSDL document.
Attempts to provide this integration have been made and typically require the use of a gateway program or proxy. These systems hide much of the detail of the web service access, including the individual ports on which the service is available. Selection of services and their ports is done using infrastructure and configuration specific to the gateway, rather than that provided by the existing messaging infrastructure.
A need exists for a mechanism which would allow web service access to integrate seamlessly with existing messaging configurations. Preferably, the invocation of the web service is customizable using a messaging product's facilities, and/or is achievable without the need for a gateway or proxy.